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Assertion  lecnanisTis  in  Projranming  Languages 


ABSIRA£I  — 

Assertions  typically  are  used  to  verify  program  behavior* 
However,  the  use  of  an  assertion  to  cause  a  run-time  exception  can 
have  practical  benifits*  We  take  this  view  that  an  exception  is 
such  an  assertion  failure* 

The  implementation  of  assertions  in  a  >»L/I  compiler  is 
described,  and  the  interface  with  the  exception  mechanism  of  PL/I 
(ON-units)  is  described*  Principle  usages  include:  test  data  set 
evaluation  and  extension  of  the  domain  of  abstract  data  type 
spec i f i cat i ons  * 
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sertioO  ecrc^nis'^s  in  ^ro^raTiminj  Languages 

I •  iDJca^wEiifio 

Assertionsi  relatively  nea  program  constructs  developed  as 
part  of  research  in  program  verification*  typically  are  used  to 
verify  program  oehavior.  They  allow  a  programmer  to  make 
statements  about  what  ought  to  be  true  at  a  point  in  program 
execution. 

The  language  designer  has  several  options  when  considering 
the  semantics  of  an  assertion  mechanism.  Originally  they  were 
considered  predicates  for  a  theorem  prover  to  (necessarily) 
verify.  Put  had  no  impact  upon  the  computation  process.  This  is 
compatible  with  the  woare  axiomatic  approach  towards  program 
verification  ChoareJ.  Alternative  views  are  that  they  indicate 
conaiiions  to  be  tested  during  program  execution  or  they  could 
indicate  a  lemma  (e.g.  theorem,  axiom,  pre  or  post  condition)  to 
oe  proven  by  the  compiler.  The  failure  of  a  run-time  check  causes 
execution  to  stop,  and  may  raise  an  exception  condition. 

The  basic  assumption  in  this  current  research  is  that 
assertions  are  another  form  of  program  exception,  rather  than 
simply  a  "Dug".  f'any  current  languages  include  some  form  of 
exception  handling  (e.g.  0*l-units  of  pl/I).  Or  stated  another 
way,  exceptions  are  simply  a  language  defined  assertion  (e.g.  an 
extension  to  the  "legality  assertion"  of  Euclid). 

In  the  next  section  of  this  paper,  several  assertion  and 


f’ 


t 


ficection  'nechanisms  now  under  stud/  are  surveyed,  while  the 


-Tirrti^o  e  -'H  i  !j.n  s  in  ‘ro^rj-nmin;  L  anajj;5e 

University  of  'aryland  PLACES  system  assertion  mechanism  is 
explained  in  section  3.  Section  4  disc'-sses  the  goals  and 
applications  Ce«g»  test  data  evaluation  and  data  type 
specification)  of  the  PLACES  mechanism  and  gives  examples  of  hoa 
to  make  use  of  the  facilities  within  PLACES. 
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2.1.  L»ceptions 

This  section  summarizes  briefly  exception  handling  in 
languages  with  assertion  mechanisms. 

2.1.1.  PU/ I 

Exception  handlers*  called  ON-units*  are  associated 
dynamically  with  exceptions.  A  program  executes  an  ON  statement 
which  dynamically  associates  a  given  block  with  a  certain 
exception.  The  block  intercepts  the  exception  as  long  as  the 
block  executing  the  CN  statement  is  active. 

At  compile  time  it  is  generally  impossible  to  identify  which 
hanjler  Ithere  can  be  as  many  as  the  programmer  wishes  to  write) 
is  active  at  the  time  an  exception  occurs.  The  environment  of  the 
0.‘.-unit  is  nested  within  that  of  the  signaling  block,  Facilites 
in  the  form  of  builtin  function  calls,  are  available  to  provide 
more  information  about  the  exception  (e.g,  ONSOuRCE).  The  ON-unit 
returns  to  the  point  -here  the  exception  was  signaled  unless  the 
2 ‘(-unit  is  terminate  J  by  a  oOTO. 


Acid 


The  new  Department  of  Defense  language  [Ada],  contains  an 
exception  mechanism.  Each  Block  or  program  body  may  have  an 
exception  handler  scatically  attached  as  an  exit  to  a  block.  when 
an  exception  is  raised  the  current  clock  is  terminated  and  control 
basses  to  the  appropriate  handler.  If  no  handler  is  specified  the 
excebtiun  i  prooagated  outward  to  the  invoking  program  unit 
(calling  program  or  enclosing  block).  Unlike  PL/I.  control 
returns  to  the  point  of  call  after  the  exception  has  been 
0  roc  e  s  s  ed  . 


2.1.3.  Gypsy 

Lxceptions,  called  condition  clauses  in  Gypsy  CAllenJ.  are 
similar  to  the  Ada  design,  with  condition  clauses  statically 
attached  to  blocks.  when  a  condition  is  raised,  the  block  is 
terminated  and  the  condition  is  processed. 


2.1.4.  Pascal, Euclid  and  ZE.nO 

•o  exception  handling  facilities  are  included  in  these 
languages,  although  some  dialects  have  implemented  some  exception 


capabil it/ 
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2.2.  Assertions 

This  section  presents  a  orief  oescription  of  the  assertion 
(nechanisK  of  several  typical  designs.  The  mechanisms  range  from 
the  eloborate  interactive  theorem  prover  of  GYPSY  to  a  simple 
rjn-time  checi^  (to  be)  generated  oy  Ada  compilers. 

'ost  assertions  are  based  upon  axiomatic  program  verification 
C'-‘oare3.  If  P  ano  Q  are  predicates  and  S  is  a  statement,  then 

{°>  S  {Q> 

states  that  if  P  is  true  (pre  condition)  ano  S  is  executed,  then  Q 
is  true  (post  condition).  The  axiom  determines  what  pre  and  post 
conditions  are  allowea. 

In  programs,  these  are  usually  written; 

ASSERT  P; 

s; 

ASSERT  0; 

Criginally  a  verifier,  if  given  the  above  needs  to  prove  {P>  S  <3> 
as  a  theorem.  Such  proofs  are  difficult  and  often  impossible. 
Thus  rjn-time  checking  was  proposed  as  an  alternative  in  several 
languages.  Note  that  this  is  essentially  a  test  of  an  instance  of 
a  variaole,  while  the  more  formal  proof  is  a  verificatian  for  all 


possible  jata 
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The  original  specification  of  Pascal  does  not  include 
assertions*  however  recent  implementations  such  as  CMansen]  Texas 
Instruments  99]  minicomputer  has  extended  Pascal  to  include  them, 
■■'ost  the  recent  languages  (e.g.  Euclid*  6TPSY,  Ada)  are 

derivaties  of  Pascal*  and  do  contain  some  assertion  mechanism. 

2.2.U.  ADA 

Ada  includes  an  ASSERT  statement*  a  boolean  expression  which 
must  oe  true  when  the  ASSERT  is  encountered  at  run-time.  If  the 
exoression  is  false  an  ASSERT  ERROR  exception  is  raised. 


2.2,3.  Euclid 

uuclid  is  a  systems  programming  language  derived  from  Pascal 
witn  reliability  ana  ve ri f i ao i I i t y  as  the  main  design  goals. 
Assertions  are  incluaed  to  provide  useful  documentation  of  program 
specifications  ana  to  assist  in  program  verification  LPopekl.  If 
an  assertion  cannot  te  proven  at  compile  time  a  run-time  check  is 
cLaced  in  the  ouject  code  by  the  compiler.  All  Euclid  programs 
are  expected  to  ce  verified,  so  the  failure  of  a  run-time  check  is 
a  fatal  error  that  stops  the  program. 

The  Euclid  compiler  is  expected  to  pass  IgatillZ 
conjitions  «hich  must  be  true  for  a  program  to  oe  legal  Euclid*  to 


_  t  -  «  1  j  t  1  ^  n  '  U 

tt'.e  verifier  whenever  the  compiler  cannot  fully  check  that  sone 
constraint  i.tiposed  oy  the  language  is  satisfied.  Legality 
assertions  are  source  level  assertions  that  can  be  inserted  by  the 
prograTmer  or  au  t  oi*  a  t  i  c  a  1 1  y  by  the  compiler  that  must  be  true 
based  upon  the  source  program.  For  example,  for  array  references, 
legality  assertions  can  be  generated  that  the  array  inoex  is 
within  the  array  oour. os. 

j .  4 .  :  £  \  0 

;£N0,  a  language  strongly  based  on  Fuclid,  is  o»ing  designeo 
for  research  in  cooe  ooti■ni^ation  ano  distributeo  computing 
L  allJ.  the  assertion  mechanism  in  ZE'JO  allows  specifications 
acout  what  is  true  at  a  point  in  program  execution  (called  22221 
assertions)  and  about  what  is  invariant  over  a  block  of  code 
(called  under  assertions). 

roint  assertions  evaluate  a  boolean  expression.  If  the 
expression  is  true  execution  continues,  otherwise  the  program 
stops.  The  compiler  is  expected  to  try  to  infer  the  truth  of  the 
expression  from  flow  analysis;  a  run-time  check  is  generated  if 
the  analysis  cannot  Drove  the  result. 

^naer  assertions  allow  invariants  to  be  placed  on  blocks  of 
code.  A  olucx  labeled  with  an  unoer  assertion  will  behave  as  if 
there  is  a  point  assertion  oefore  each  statement  in  the  block  and 
a^ter  the  last  state''ent  of  the  block.  Under  assertions  normally 
apply  to  all  inner  clccxs  but  a  relax  clause  can  oe  added  to  an 
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inner  alock.  to  release  the  inner  block  from  conforming  to  the 
unde  r  assertion. 

2.2.5.  GYPSY 

The  orime  design  goal  of  GYPSY  ^as  an  integrated 

specification  and  orogramming  language  CAllenD.  The  assertion 
mecnanism  of  GYPGY  is  used  to  express  program  specifications. 
S  i  f  i  c  a  t  i  on  s  can  be  placed  on  type  parameters  (REauiRE), 

statements  (ASSERT)  and  routines  (ENTRY,  SLOCK  and  EXIT).  The 

progranmer  can  request  that  the  compiler  prove  or  assume  any 
specification.  The  compiler  can  also  be  directed  to  include  a 
run-time  check  of  the  s pec i f i c a t i on.  failure  of  the  run-time 
check  raises  an  exception. 

2.2.6.  PL/ C  S 

PL/CS  is  a  version  of  PL/I  developed  at  Cornell  university 
which  "enforges  some  of  the  ioeas  which  have  come  to  be  regarded 
^5  good  e£29ramming  BEiSllSl”  CConwayl.  The  PL/CS  assertion 
mechanism  includes  an  ASSERT  boolean  expression  with  two 

variations. 

The  FOR  S0‘-1E  variation  attaches  a  00  group  to  the  assertion. 
The  expression  must  evaluate  to  ’’true”  for  at  least  one  value  of 
the  index  variable.  For  example,  suppose  we  wish  to  assert  that 


some  element  of  the  array  Y  of  dimension  N  is  greater 


than 


zero. 
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r  j 


«e  .oulo  -rite: 

ASSEHT  (xcn  >  3)  FOR  SOME  I  =  1  TO  N; 

The  FJA  all  variation  is  similar,  however,  the  boolean 
e»cression  must  Le  true  far  all  values  oF  the  index  variable, 

7he  ,’L/C,.  assertion  mechanism  is  intended  to  be  used  as  a 
testinj  a i 0 ;  the  assertions  can  oe  turned  off  by  compiler  option 
tor  prodjction  runs. 


.  i c  r  t  i  ^ in  l  •:  :< 


ilsertisQS  in  PL4t£S 

The  Places  project  (Projramming  Language  ana  Construct 
Evaluation  System)  is  a  research  project  of  the  University  of 
''ar/lano.  By  using  the  PLUM  load  and  go  PL  / 1  compiler 
CZelVoaiti  a3  as  a  basis,  the  compiler  has  been  extended  to 
integrate  assertions  within  the  exception  hanaling  capability 
(i.e.  ON -units)  of  PL/I. 

The  model  being  implemented  is  a  merger  of  verification  and 
testing  strategies.  Similar  to  Euclid,  the  programmer  sprinkles 
the  code  with  assertions.  A  verifier  tries  to  prove  the 
assertions.  If  so,  then  the  assertion  can  effectively  be  deleted 
CEigure  5-1j.  If  not,  then  the  assertion  remains  as  a  run-time 
check.  Differences  from  Euclid  include,  the  failure  of  the 
run-time  check  to  invoke  an  exception  handler,  allowing  the 


programmer  to  take  some  action  other  than  stopping  the  program 
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FIGJRE  3-1  PLACiS  Structure 
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In  -nany  a  pp  I  i  c  a  t  i  on  s  ,  oroi,rams  cannot  be  proven, 
exaitple,  j  i  ven  the  sequence: 

GET  list  (X); 


the  correctness  of  the  program  may  depend  upon  the  value  o*  x 


«hich  cannot  ce  kno.n  until  run-time. 


A  perfect  system  (which  we 


-  .  S  e  r  1  ^  rs,  c  T  f-  ^  ^  ^ 

00  not  c I d i m  to  oe  producing)  dOuld  reduce  all  assertions  to  the 
tollo-inj  one: 

GET  list  (X); 

ASSERT  (Plx)  )  ; 

*nere  Plx)  is  the  ori»aicate  that  **x  has  the  oroperity  that  ensures 
the  correctness  of  the  prograin**.  Thus  the  correctness  of  a 
crojrait  run  deoenos  on  one  specific  run-time  check.  In  the 
example  of  figure  3-1’  the  assertions  at  lines  2c-23  and  29  can  be 
proven  (see  Ccasili])  ano  hence  deleted,  «hat  remains  is  P(X), 
where  x  is  the  vector  Ca,3]  and  p(x)  is  (a  >  3  i  d  >  C>. 

3.1.  i-dsic  ASSERT  statement 

The  basic  ASSERT  in  PLACES-  has  the  form: 

ASSERT  (< boolean  expression>); 

•hich  generates  a  run-time  test  equivalent  to: 

IE  NOT  (<boolean  exoression>;  then  SIGNAL  ASSERTFAIL; 

In  otner  words,  if  the  boolean  expression  is  ''true'*  execution 
continues,  otherwise  the  ASSERTFAIL  conoition  is  raised. 
A-SERTFAIl  -as  aJceo  as  a  new  conoition  which  can  be  invoked.  Thus 
the  user  can  ,rite; 

ON  ASSERTTAIL  dEGIn  .  .  .  END; 

Examcles  of  PLACES  assertions: 

assert  (X  >  Y); 


A'.  (A  <  l;  C  »  3); 
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ASSERT  (A);  /•  valid  C\LY  IF  A  IS  DECLARED  BIT  */ 

This  is  similar  to  oth^r  run-time  assertion  systems. 

3.t.  Invariant  assertions 

Cft»“n  it  is  uesiraole  to  have  an  assertion  holO  over  a  olock 

o^  coje.  Places  hanoles  this  via  an  invariant  iSSeriign  of  the 

tom; 

ASSERT  (<boolean  ejipression>)  INVARIANT; 

Si-ilar  to  iENOi  an  invariant  assertion  generates  a  test  of  the 

e»oression  before  each  statement  at  the  same  scope  level  in  the 

remainder  of  the  current  clock.  The  expression  is  also  tested 
after  the  last  statement  in  the  clock.  It  should  be  noted  that 
while  the  invariant  is  checked  oefore  entry  to  and  after  exit  from 
a  block  nested  within  the  current  scope*  the  invariant*  unlike 
^£^0,  is  not  checked  within  an  inner  block  unless  it  is  explicitly 
stated. 


i.3.  .artieo  Assertions 

PLACES  assertions  are  non -executable  statements  in  that  they 
cannot  be  labeled  or  referenced  by  a  6CT0  statement  and  have  no 
sice  effects.  nowever,  it  is  sometimes  desirable  to  re^er  to  a 
SLecific  assertion.  To  this  eno  assertions  can  be  named.  The 
s/ntax  IS  as  follows: 


ASSERT  C<nam»'>} 


(<bool?an  exDression>)  (Inva'>IANT}; 


■  s  e  r  t  i  0  s  in 


w  V.  ■ 


where  the  itenis  in  orackets  (<na(ne>  and  INVARIANT)  are  ootional* 
and  <nanie>  refers  to  any  lejal  PL/I  identifier. 

3. A.  GNA5SERT  builtin  function 

Given  several  assertions  within  a  program,  if  a  user  writes 
an  ASSESTFAIL  CN-unit,  the  ability  to  determine  which  assertion 
tailea  is  needea.  In  oraer  to  oo  this,  the  ONASSERT  builtin 
♦unction  was  aaoed.  ONASSERT  returns  a  character  string  which  is 
the  name  of  the  assertion  which  raised  the  exception.  If  the 
failed  assertion  was  not  named  the  statement  number  of  the 
assertion  is  returned. 

ose  of  named  assertions  and  ONASSERT  leads  to  a  model  of  an 

0\-jnit  that  has  practical  applications,  for  example,  an 

ASSERTFail  CN-unit  could  have  the  structure: 

ON  ASSERTFAIL  BEGIN; 

00  CAGE  (CNASSERT); 

N^LAoELI^V  OO;  ...  END; 

\'LA6EL2'\  00;  ,  .  .  END; 

• 

END;  /•  END  CASE  •/ 

END;  /*  END  ON -UNIT  */ 

This  has  a  sematic  structure  similar  to: 

ON  ASSERTFAIL  EEGIN; 

WHEN  \LA5£L1N  DO;  .  .  .  END; 
wHE’*  NlAB^LTN  D'j;  .  .  .  tND; 

• 

L  *f  u  ; 

♦his  Structure  is  :3uite  si'^ilar  to  CtPSt  and  AD*. 


5.5.  Lxecution  Soniinary 


,heo  a  places  program  terninates  a  summary  is  printed  giving 
tor  eacn  assertion  t^e  number  of  executions  and  the  number  of 
failures. 

3.C.  An  Example 

The  program  in  Eigure  5-£,  aaapted  from  Coasili]  multiplies 
t -o  numoers  by  repeated  audition.  The  ASSERT  statements  are 
present  at  lines  13f  22-23  ana  29.  The  assertion  at  lines  22-23 
is  an  example  of  an  invariant.  Tne  expression  is  tested  after 
eacn  statement  in  the  remainder  of  the  enclosing  clock.  That  is* 
the  invariant  is  checked  after  each  statement  between  lines  23  and 
2  . 

If  any  of  the  assertions  fail  the  ON-unit  in  lines  f  to  1?  is 
invoked.  This  u‘J-unit  prints  a  message  identifing  t^e  failed 
assertion  and  tne  statement  where  the  failure  occured.  If  the 
assertions  at  lines  lb  or  29  fail  ONASSERT  returns  the  statement 
numoer  of  the  AjStRT,  which  is  12  or  22  respectively.  However  if 
the  A.5ERT  at  lines  22-2!  fails,  ONASSERT  returns  L 00 P _I N V AR I  A N T 
since  tne  assertion  is  namej. 


figure  3-2  Pt-ACf.S  Program  «ith  Assertions 


Pl.U'i  5:1^^  <PVaces  PrQject>  10/31/79  10:12:46 

1  1  "'UL  tPfiOCEOUfi  E  options  (MAIN); 

Z  2  DECLARE  (A,e,r,z); 

3  2 

4  ’  DECLARE  >’0»E  INPUT  BIT  (1)  INIT  ('1'B); 

5  3 

6  4  ON  ENDFILE  (SYSn)  PORE  INPUT  =  '0'5; 

?  4 


E  6 
^  6 
10  6 
11  6 
12  6 

13  E 

14  3 

15  13 

16  11 

17  11 

1?  12 
19  13 

14 

21  15 

22  1 5 

23  16 

24  17 

25  1  i 
Zt  19 

^  ^  3  n 

u  '  ^ 


32  23 

33  24 

34  25 


ON  ASSERTFAIL  put  skip  edit  ( 

'assertion  '.ONASSERT,'  failed  at  ,0NSTWT ) 
(A,A,A,F(i)); 


Put  skip  list  ('enter  a  and  b'); 

GET  LIST  (A,B); 

DO  -HILE  (MORE. INPUT); 

PUT  Skip  data  (a,8); 

/•COMPUTE  I  :«  A*8  BY  ADDITION  */ 

ASSERT  (A  >=  u  s  B  >=  0); 

Z  =  0; 

Y  =  B; 

BEGIN; 

ASSERT  LOOP. INVARIANT 

(Z  =  A*(o-Y>  i  Y  >st  0)  INVARIANT; 
00  «HILE  (Y>3); 

Y  =1  Y  -  1 ; 

Z  =  Z  ♦  A; 

END; 

END; 

ASSERT  (Z  *  A*8); 

OUT  SKIP  EDIT  (A,'  •  '.Bt'  *  ',Z) 

(  F  (3 ) , A,F  (  3)  f A, F (4)  )  ; 

PUT  SKIP  LIST  ('ENTER  A  AND  3'); 

GE^  LIST  (A, 3); 


36  Z? 

END 

•"LL; 

,  A  =  NI  .,G 

CS 

e  -■ 

>  u 

AGSERTfaic.  is  non-s  t  andard  PL/1 

warning 

CG 

52 

ONASSERT 

is  non- s t anda rd  °L/1 

A  4  N  1  N  G 

CG 

52 

CNS’MT  is 

non-St  anoa  rd 

PL/  1 

«  A  "  %  I  t  G 

CG 

52 

ASSERT  is 

non-s  t  a  noa  rd 

PL/1 

cr-'-PlLE 

*■  I  M 

c 

MSE 

C . 

^  S  r  r  t  1 


Figure  3-3 

Output  from 
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1  9 
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1  9 

ASSc  RTI ON 
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1  9 
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0 
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A  = 

9  = 

ASSERTION 

LOOP 

.INVARIANT 

FAILED 

AT  : 

19 

assertion 

LOOP 

.INVARIANT 

failed 

A  T  : 

19 

ASSERTION 

LOOP 

.INVARIANT 

failed 

AT  : 

19 

ASSERTION 

LOOP 

.INVARIANT 

FAILED 

AT  : 

19 

A  SSE  RTI ON 

LOOP 

INVARIANT 

FAILED 

AT  : 

19 

-  *  5  =  4G 

£x  Normal  exit 

ASSERTION  SUMMARY; 

STMT  *  EXECUTIONS  FAILURES 

1  2  2 

1  5  I N  V  3  ?  £ 

-r  •> 

k  w 

E  XECUTI  ON  T  I'^E  1  31  3  MSEC. 

3.7.  iohancements  Under  st uoy 

additional  features  to  '’LACES  are  still  under  study; 
since  tney  can  oe  simulated  relatively  easily  within  the 


however, 

current 


-iSertiGos  ir 


structurei  the  implementation  has  been  postponed. 

After  evaluation  these  features  may  be  added  to  the  language: 

1)  Initial  values.  5X  corresponds  to  the  initial 
value  of  X  on  entry  to  a  block. 

X  can  only  be  tested  within  an  ASSERT  statement.  Now 
the  programmer  can  simoty  declare  a  variable  and 
initilize  it  in  order  to  simulate  this. 

2)  FOR  ALL  and  FOR  SOME.  These  constraints  Clike 
in  ®L/CS)  are  also  ueing  considered.  They  can  be 
simulated  as  function  calls  within  expressions  in  ASSERT 
statements. 


U  '3  i  T  j  ■  i  s  e  r  '  1  y  r  i  in  '  r  o  ■.  r  ,i  -n  i 

ySlGd  iSSSIliSDS  22  ?£23!!i!!!l 

4.1.  Provide  Information  to  a  Compiler 

Assertions  can  be  used  to  urite  specifications  which  a 
compiler  tries  to  prove.  Tnis  has  not  been  very  fruitful  in 
general  Decause  of  the  difficulty  of  writing  good  theorem  provers. 
However,  many  simple  assertions  and  special  cases  can  be  checked 
at  compile  time  with  techniques  such  as  data  flow  analysis. 

4.2.  Program  Testing 

Assertions  can  be  used  in  program  testing  to  verify  pre  and 
post  conditions  and  to  monitor  constant  relationships  i.e., 
invariants.  Some  general  rules  of  thumb  should  be  followed  when 
using  assertions  in  program  testing  (some  of  which  can  be  enforced 
by  the  comp i le  r )  . 

1)  Assertions  should  not  be  referenced  except  by 
some  other  component  of  the  assertion  mechanism  such  as 
an  ASSERTFAIL  ON-unit. 

2)  Assertions  should  be  used  so  that  they  can  oe 
deactivated  without  changing  the  meaning  or  results  of  a 
program.  They  should  not  be  used  to  screen  input  for 
validity,  for  example. 


s  1  n  ^  '•  'j  s  t  r  t  i  c  n  i  in  r  o  r  -3  ■»>  S 

Qt  course,  these  guidelines  do  not  apply  when  assertions  are 
use  for  some  purpose  other  than  testing. 

4.2.1.  Pre  ana  Post  Conditions 

One  method  of  using  Assertions  is  as  pre  concitions  or  post 
conaitions  on  logical  groups  of  statements.  When  used  as  a  pre 
condition  an  assertion  verifies  that  the  previous  statements  have 
executed  correctly,  i  .e .  ,  it  is  a  post  condition  on  the  statements 
already  executeo. 

4.2.2.  Invariant  Assertions 

Another  usage  of  assertions  is  to  monitor  a  relationship 
among  variaOles  which  must  remain  constant  over  a  block  of 
statements.  This  can  be  done  by  an  invariant  assertion  as  in 
lines  22-23  of  figure  3-2.  It  should  be  pointed  out  that 
invariant  assertions  cannot  in  general  be  used  to  specify  loop 
invariants  in  the  Hoare  sense  since  a  loop  invariant  often  fails 
to  nold  within  the  body  of  a  loop. 

4.2.3.  Test  Data  Evaluation 

-ssertions  can  be  used  to  help  evaluate  the  thoroughness  of  a 
test  data  set.  'y  placing  assertions  along  each  control  path  the 
assertion  summary  of  PLACES  identifies  which  paths  have  not  been 


executeo 


''sin;  '-sscrtii^ns  in 

For  example*  in  Figure  4-1  the  execution  count  of  the 
assertion  «iHILE1  is  the  numoer  of  times  the  while  loop  is  reached 
during  execution.  The  failure  count  is  the  numper  of  times  the 

looD  is  skipped.  So  by  examining  the  execution  summary  the 

programmer  knows  if  the  test  data  set  has  exercised  the  loop  or 
skipped  it  or  both. 

Figure  4-1  Using  /Assertions  in  Path  Testing 

ASSERT  WhILEl  (A  <  9); 

LOOPrDO  while  (A  <  6); 

END; 

Of  course,  even  if  all  oaths  of  a  program  are  executed  by  a 
test  set  there  can  still  be  errors  in  the  code  CGoodenough] .  The 
main  thrust  of  program  testing  is  to  expose  program  errors.  It  is 

believed  that  the  more  components  of  a  program  that  are  exercised 

the  lower  the  chance  of  undetected  errors.  A  careful  selection  of 
assertions  can  provide  more  information  than  path  testing  alone. 

In  figure  4-i  the  assertions  0R1 ,  0R2  and  0R3  indicate  the 


c  omo i na  t i on  of 

c  ond i f i on  s 

leading  to  execution 

of  the  Then 

path 

of 

I  FI.  I  FI  is 

an 

example 

of  monitoring  a 

d  i  s  j  u  nc  t  i  on 

0  f 

t  wo 

expressions. 

A  n 

example 

of  monitoring  a 

c  on  j  u  nc  t i on 

0  f 

two 

.  1 


expressions  is  presentee  in  IF2 
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Fiyjpe  ^-2  Monitoring  Path  Selection 


declare  G0T_HERE  elT  INIT  ('1'B); 

(A  >”b  OP  c  <  0)  the'j  do; 
assert  ORI  (A  >  9  C  <  0); 
assert  0R2  (A  >  B); 

ASSERT  0R3  (C  <  D); 


E'^D; 

ELSE  DO; 

ASSERT  (G0T_HERE); 


E  ‘.D; 

IF  2  :  : F  (A  >  0  V  C  <  0 )  then  DO; 
ASSERT  (GOT  HERE); 


£  VD; 

ELSE  DO; 

assert  (NOT  (A  >  B  OR  C  <  0)); 
ASSERT  (NOT  (A  >  o))  ; 

ASSERT  (NOT  (C  <  0)); 


4.3.  Exceptions  Viewed  as  Assertions 


«e  have  oeen  viewing  assertion  failures  as  one  out  of  several 
classes  of  exceptional  conditions;  usually  they  are  signifing  an 
incorect  program.  However,  this  is  in  fact  oackwards,  other 
exceptions  are  in  reality  assertion  failures.  Any  language  has 
certain  data  type  constraints  (e.g.  division  is  with  a  non-zero 
divisor),  and  violating  those  constraints  raises  an  exception,  we 


'■'.i'ly  ‘iScrticrs  in  ro  :  ra  t,  i 

believe  tnat  this  is  a  more  reasonable  viewpoint.  Conjidert  for 
eiample,  the  statement  1  =  4  ♦  K.  when  the  programmer  writes  such 
a  statement  she  (or  at  least  the  compiler)  has  in  mind  the 
a  sse  r  t  i  on  : 

'^IN_IMEGER  <  (J  *  K)  AND  (J  ♦  K)  <  MAX_INTEGER 
where  '^IN_1NTEjER  and  '^ax_INTE3ER  are  the  smallest  and  largest 
integers  r e p re se n t a o  I  e  within  the  implementation.  If  this  implied 
assertion  fails  an  overflow  exception  is  raised.  This  sort  of 

imolied  assertion  has  been  extended  as  the  legality  assertion  of 
Euclid. 

«ith  this  view  we  have  more  flexibility  in  thinking  about, 
designing  and  using  an  assertion  mechanism.  we  can  have 
assertions  check  for  boundary  conditions  and  process  these  special 
cases  elsewhere  in  an  exception  handler.  Our  code  is  not 
cluttered  by  the  details  of  handling  special  cases,  as  the 
following  section  demonstrates. 

A. 4.  Data  Type  Specifications 

In  an  earlier  paper  EZelkowitz  b3.  an  extension  to  PLUM  has 
been  described  which  implements  abstract  data  types  called 
ENVIRONMENT  variables,  a  form  of  pointer  variable  implementation 
with  protection  against  invalid  usages*  ‘'‘he  model  that  was 
imolemented  has  the  following  structure.  For  a  data  type  STACK 
with  ooerations  PUSn  and  POP.  the  source  code  implementing  the 
abstraction  woulo  be: 


u  - 


iiO';  'iStrtions  in  ro^rjns 


STACn:A3STkACTI0N; 

DECLARE  1  STACK, 

J  STORAGE  (IDO),  /*  STACK  IS  AN  ARRAY  */ 

Z  CURRENT^PTR  INIT  CO), 

Z  SIZE  INlT  (100); 

PUSH tFUNCTION  (X,Y);  /*  PUSH  Y  ONTO  X  */ 

DECLARE  X  ENV(STAC<); 

DECLARE  Y; 

•  •  • 

END  PUSH; 

POPrFUNCTlON  (X);  /*  POP  X  AND  RETURN  TOP  VALUE  */ 

•  •  • 

END  POP; 

END  stack; 

A  user  of  a  stack  woula  code: 

DECLARE  X  ENV  (STACK); 

•  •  • 

.CALL  PUSH  (X,l); 

•  •  • 

I  =  POP(X); 

and  would  only  have  access  to  the  data  type  name  STACK  and  the 
operations  PUSH  and  POP. 

Assertions  fill  the  role  of  specifications  for  this  model. 
For  example,  the  PUSH  operation  could  have  the  syntax: 
PUSHiFUNCTION  (X,Y); 

assert  PUSH_FAIL  (X .CURRENT_PTR  <  X.SIZE); 

•  •  • 

END  PUSH; 

Thus  the  implementation  need  not  de  concerned  with  improper  calls 

on  PUSH  since  the  assertion  ensures  (either  through  a  proof  or  a 

run-time  check)  that  the  condition  cannot  arise.  The  full 

implementation  of  a  STACK  can  then  Pe  coded  as: 

STACk:A3STRACTI0N; 

ON_UNIT:PROCEDURE; 

•HEN  PLSH_FA1L  BEGIN  .  .  .  END; 

WHEN  pQP.FAIL  begin  .  .  .  END; 

•  •  • 


j  i  o  'j  ■  s  s  e  r  t  i  c  n  i  in  '  r  o  j  r  a  s 

END  0N_UN1T; 

•  •  • 

PUSH -.FUNCTION  (X,V); 

ON  ASSERTFAIL  call  0N_UNIT; 

ASSERT  PUSH_FAIL  <e xp re s s i on >; 

•  •  • 

END  PUSH; 

END  STACK; 

One  i mpl ement d t ion  detail  under  consideration  is  to 
automatically  execute  the  statement: 

ON  ASSERTFAIL  CALL  ON_UNIT; 

on  entry  to  the  function*  thus  have  exceptions  handled 
automatically.  This  leads  to  a  practical  system  that  has  many  of 
the  same  characteristics  as  alpharo  CWulf3  in  a  practical  system. 
The  ON  statement  in  procedure  PUSH  can  automatically  oe  generated 
if  there  is  an  exception  block  at  the  head  of  the  proceoure.  These 
ideas  are  now  under  development. 
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